NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/9818

Internet Message Format | 1996-08-05 | 4.0 KB

Path: keats.ugrad.cs.ubc.ca!not-for-mail
From: [e-mail] (Kazimir Kylheku)
Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++
Subject: Re: C/C++ knocks the crap out of Ada
Date: 4 Mar 1996 08:50:09 -0800
Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <4hakfl$[e-mail]>
NNTP-Posting-Host: keats.ugrad.cs.ubc.ca

In article <4hakfl$[e-mail]>,
Alan Brain  <[e-mail]> wrote:
 >[e-mail] (Kazimir Kylheku) wrote:
 >
 >
 >>You are confusing the language specification with the implementation. The C
 >>specification does not call for the ability randomly access memory. The only
 >>way to legally manufacture pointers is by taking the addresses of named
 >>objects, using the standard defined function malloc() or through pointer
 >>arithmetic (adding an integral displacement to an existing pointer---an
 >>operation which yields undefined results if you try to create a pointer outside
 >>of an object). You aren't even legally allowed to subtract two pointers that
 >>don't reference the same object, even if they have compatible types.
 >
 >Agree. But if a Cosmic Ray comes and Zapps a bit, this could happen. Or if a
 >memory chip wasn't quite up to par. Ada 83 will catch it at the next
 >type-check, raise an exception, and trigger whatever error-correction has been
 >designed into the program. Yes, if that's insufficient, you have problems.

Ada compiled code will catch this? My ass. The hardware is supposed to catch
this, by implementing _at the very least_ a parity bit for detecting single-bit
alterations in dynamic RAM.  For more robust reliability, you want more bits
than that so that you can implement Hamming code error correction and
detection.

What if the toggled bit is in the middle of an integer or a floating point
number's sign, mantissa or exponent such that the alteration results in a
perfectly valid number?

 >>Whether C is more or less unsafe than Ada is truly debatable.  A
 >>standard-conforming, _quality_ implementation of either language coupled with
 >>adherent programs subject to rigorous quality control is suitable for
 >>safety-critical software.
 >
 >See above example. EVEN IF THE CODE IS BUG FREE ( a big ask IMHO ) there will
 >occur problems - hardware problems - which the C language cannot detect by its
 >very nature, and so cannot correct. Ada 83 gives a greater - though not
 >absolute - ability to the programmer so the program can cope with bugs, hard
 >failures and soft failures, and STILL work. Sorry, but being able to say to
 >the relatives 'No fair, it was a cosmic-ray induced glitch, the software was
 >bug free' cuts no mustard if the plane crashed as the result of an
 >out-of-index parameter.

What if the parameter is altered in such a way that it stays within the index?
I suppose that you have a proof that this is safer and more reliable. After
all, if a mechanical arm is safer when it stays within certain physical limits,
surely an array index or pointer inside a digital computer is safer when it
stays within bounds, right?

Keep dreaming in your imaginary world...

 >To give a concrete example, I - along with some very inexperienced programmers
 >- recently wrote a Threat Evaluation and Weapon Assignment segment. One which
 >would kill people if it didn't work exactly right, either by shooting at
 >friendlies, or allowing a missile through to hit the ship.

That's why they assigned you to it, along with some very inexperienced
programmers!  Right on. Glad to know tax dollars are hard at work.

 >That's the key to success in my experience. Ada 83 code cannot be Bug-Free,
 >but it can be Bug-Resistant. C - except in certain ways, and with an
 >increase of up to 10 times the coding effort - can't.

How do you know that? Most of the kinds of things you describe (e.g. range
checking) can be handled by a specialized compiler.
--